Release 10.1A: OpenEdge Development:
Programming Interfaces

Application design considerations

For any client/server application, where the client is accessing databases directly, generating application events is straight forward. You invoke the appropriate methods on the AUDIT-CONTROL system handle and OpenEdge ensures that the corresponding audit event records are recorded to every connected and audit-enabled OpenEdge RDBMS.

However for an n-tier application, especially an OERA-conformant application, where the AppServer client does not access any data sources directly, you cannot execute application event methods directly on the client. Especially for a WebClient, because there is no connected database, these methods execute without effect.

Supporting OERA-conformant clients

To support auditing for an OERA-conformant client, you must create an API on the AppServer especially for generating application events on behalf of the client. The granularity of this API from the client perspective is entirely application-dependent. You can provide remote procedure or user-defined function calls, perhaps parameterized, that generate one audit event at a time to reflect client-specific conditions, or you can simply hide AUDIT-CONTROL method calls inside task-oriented application service calls, such as inventory look ups or other application-specific operations.

If you require a fine-grained application event API to audit client-specific conditions, you might also need to examine active audit policies to identify active application events that the API can generate for specific client calls. It all depends on how general your application event API must be to cover the application functionality.

Examining active audit policies

To examine active audit policies in the AppServer session, you must ensure that the database connection ID for a given audit-enabled database has the Audit Data Reporter or Audit Administrator privilege set for it. You can then access the active audit policies in the following ways:

Directly access audit policy tables in each connected and audit-enabled OpenEdge RDBMS.
Access appropriate query procedures supported by the OpenEdge Audit Policy Maintenance APIs.

The Audit Policy Maintenance APIs represent a set of 4GL persistent and non-persistent procedures that allow you to query audit policies or perform audit policy maintenance tasks, depending on your audit privileges.

For purposes of querying active audit policies, you can use the following procedures from these APIs:

get-policies-merge internal procedure of the generic utility API (_aud-utils.p persistent procedure). This procedure returns data about active policies only. However, you must use other procedures in the API to load a ProDataSet with audit policy data from audit-enabled databases before you can access the active policy information.
_get-policies.p non-persistent procedure. This procedure loads all of the audit policies in a given audit-enabled database into a ProDataSet. You can then query the ProDataSet for active audit policy data. If you want to query more than one database, you must invoke the procedure for each one.

These procedures are all located in the following OpenEdge installation location:

OpenEdge_install_dir\src\auditing\

For more information on using the Audit Policy Maintenance APIs and the audit policy tables, see the "Custom audit configuration tools" section. For more information on the Audit Policy Maintenance APIs themselves, see Appendix B "Audit Policy Maintenance APIs."

Once you have identified auditable application events, as specified in active audit policies, you can invoke the AUDIT-CONTROL:LOG-AUDIT-EVENT( ) method for an appropriate application event in response to a client call to your own application event API.